書評「入門　監視」雰囲気で監視をやっているすべての人にオススメ

監視という一種マニアックな領域を真正面から解説した貴重な本です。監視で悩む人のみならずシステム開発に携わるすべての人にオススメ。

#監視

#監視サービス

#AWS

濱田孝治

2019.01.21

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

「全然わからない。俺たちは雰囲気で監視をやっている」

自分はAWS事業本部コンサルティング部所属ということもあって、いろんなお客様にAWSインフラのコンサルティングしてます。最初のインフラ構成設計時に監視の話をすることも非常に多いんですが、

「どうしましょう。CloudWatchでいけますかね？」
「MackerelとかDatadogとかもありますが、どうしましょ。マネージドとの違いは〜」
「とりあえず、ディスク使用率80%でしきい値設定しておきましょうか。みんなそうしてますよ」

とか言っていた昔の自分に見せつけたい本、それが今回紹介する「入門　監視」。

監視設計の原則がよくわかんない
メトリクスのしきい値決めるところから監視を考えてしまいがち
よく考えずに、いろんなメトリクスをアラート対象にしてしまう
雰囲気で監視をやっている

そんな人達に、オススメの書籍でございます。

　__
（祭） ∧ ∧
　Y　 ( ﾟДﾟ)
　Φ[_ｿ__ｙ_l〉     監視ﾏﾂﾘﾀﾞﾜｯｼｮｲ
　　　 |_|＿|
　　　 し'´Ｊ

書籍情報「入門　監視」

入門監視 ―モダンなモニタリングのためのデザインパターン

著者、訳者

著者：Mike Julian（マイク・ジュリアン）
松浦　隼人（まつうら　はやと）

また付録では、Mackerel（マカレル）のプロダクトマネージャーとチーフエンジニアを務める松木雅幸さん（@songmu）も、執筆されています。

第Ⅰ部　監視の原則
1章　監視のアンチパターン
2章　監視のデザインパターン
3章　アラート、オンコール、インシデント管理
4章　統計入門
第Ⅱ部　監視戦略
5章　ビジネスを監視する
6章　フロントエンド監視
7章　アプリケーション監視
8章　サーバ監視
9章　ネットワーク監視
10章　セキュリティ監視
11章　監視アセスメントの実行
付録
付録A　手順書の例：Demo.App
付録B　可用性表
付録C　実践.監視SaaS

全編面白いので、あとは、自分の琴線に触れたところを中心に主観強めで書いていきます。

重要「1章　監視のアンチパターン」

優れた監視を実装する旅を始める前に、これまであなたが選んだり、見てきたであろう良くない慣習を特定し、直す必要があります。

のっけから、刺激が強い。最初から具体的なシチュエーションが諸々挙げられているので、自分の監視について問題意識を持ちながらこの本を持った人は、胃が痛くなることでしょう。

特に「アンチパターン1：ツール依存」「アンチパターン3：チェックボックス監視」は、とかく手段と目的を混同しがちな組織における監視アンチパターンの超あるあるな事項が記載されているので、「おう…」と日頃の現場を思い出す人も多いんじゃないでしょうか。

こういった書籍の場合、ベストプラクティスや原則から始まるのが普通だと思うんですが、このアンチパターンの説明により、自然と筆者が考える監視の枠組みが浮き彫りになります。抽象的な概念より、現場のシチュエーションを元に記載されているので、入りが良いし、次章以降が楽しみになります。

「2章　監視のデザインパターン」

この章では、真剣に受け止めて実装すれば、監視の最高の境地に達することができるデザインパターンを示し、疑問に答えていきます。

1章との組み合わせで、筆者が考える監視のデザインパターンが示されています。

データ収集
データストレージ
可視化
分析とレポート
アラート

一口に監視ツールといえども様々ある中で、監視ツールの機能ではなくそのコンポーネントとして一段深い説明があるので、非常に頭の中が整理できます。データ収集における「プッシュ」と「プル」の特性の違い、メトリクスとログの違い、データストレージの特性などの説明があり、特にアラートの部分についての以下の記述は目を引きます。

監視は質問を投げかけるためにある

「デザインパターン3：作るのではなく買う」では、いわゆるサーバー導入型の監視ツール（Prometheusなど）と、SaaS型監視サービス（DatadogやMackerelなど）のメリットデメリットが述べられています。

ここごっつ面白い。特にアプリケーションの成長過程でどちらのほうがメリットが有るのかを冷静に比較するべきポイントは、これからまさに監視システムを導入しようという組織の参考になるんじゃないでしょうか。フリーのツールを導入するとき、それが運用や体制を確立する上で本当に安いと言えるのか？SaaSで十分なのではないか？などが、理由とともに述べられています。

まぁ、乱暴に言ってしまうと、ぶっちゃけこの本では、基本SaaS推しです。

超重要「3章　アラート、オンコール、インシデント管理」

どうしてそういう問題はいつも午前3時に起きるのでしょうか。

(´；ω；｀)ﾌﾞﾜｯ

監視において「アラート」は重要ですね。頻発するアラートに体力や集中力をそがれ「オオカミ少年アラート」に誰も目を留めなくなり、そのうち重要なアラートメールを見落としシステム完全停止…　非常にあるあるすぎる悩みで震えます。

自分がもっとも大事だと思うのがこの章で、そういった「アラート疲れ」「オオカミ少年アラート」に対して、「良いアラート」を設計するための具体的な手法が解説されています。

よくやってしまいがちなアラートの例として、「固定の閾値を決めておいて、それを超えたらアラート」というのがあると思いますが、これに意味がない場合も多いですね。例えばディスク利用率80%の閾値を決めておいたとして、急激なディスク容量の変化（1日でディスク利用率が20%〜70%になったとき）は気づけません。

こういう場合には、移動平均、信頼区間、標準偏差など、メトリクスに対する統計的な扱いが必要ということが解説されています。

「本当にそれがアラートとして必要なのか？」という問に対して、改めて考えるきっかけをもらえる素晴らしい章です。

（私見）考えを改めさせられた、Amazon CloudWatchアラームの利用方法

自分AWS脳なので、改めてCloudWatchアラームの利用方法のドキュメントをみていたんですが、以下の記述があることに気づきました。「持続した状態変化に対するアクション」というキーワードがでてきます。

アラームは、持続している状態変化に対してのみアクションを呼び出します。CloudWatch アラームは、単に特定の状態にあるというだけでアクションを呼び出すわけではありません。状態が変わり、それが指定した数の期間にわたって持続している必要があります。

引用：Amazon CloudWatch でのアラームの使用 - Amazon CloudWatch

ヘルスチェックのような仕様を、カスタムメトリクスの0 or 1に変換して、CloudWatchアラームでアラートをあげるという実装をしたことがあるひとも多いと思います。もちろん使えますが、アラームが即座にあがるような使い方は期待できません。これは、おそらく本来のCloudWatchアラームの利用用途とは異なる使い方をすることの利用用途の違いからでているものと思われます。

「4章　統計入門」

前章で「固定のしきい値に意味がない場合が多々ある」という問いに対する、具体的な答えとなる章で、以下の統計的手法が紹介されています。

算術平均
移動平均
中央値
周期性
分位数
標準偏差

今まで「固定のしきい値」と「平均」ぐらいしか頭になかった自分にとって、改めてメトリクスの処理方法を俯瞰できてよかったです。CloudWatchアラームにも任意の数式を設定できる機能（参考：Metric Math を使用する - Amazon CloudWatch）があるので、ここらへん見返して、アラート条件を見返してみるのも良いんじゃないでしょうか。

重要「5章　ビジネスを監視する」

この章の最後には、経営層の関心事に深い認識を持ち、彼らが楽に仕事できるようにすることで、監視がビジネスに提供する価値を明示できるようになるはずです。

最終的にアプリケーションが実現したい、ビジネス的KPIを真っ先に定義・確認するのが活きた監視をするための絶対必要条件。エンジニア脳だと、どうしても各コンポーネントの機能からボトムアップ的に考えがちですが、その考え方をやめてビジネス視点でアプリケーションを捉えてそれを具体的な監視メトリクスに落とし込む手法が紹介されています。

設定しているアラートやメトリクスについて、「何が良いのか何が悪いのか、必要なのか不要なのかわからん…」という気持ちになっているときは、大抵ここの整理が中途半端だと思われるので、再整理するのが良いでしょう。

「6章　フロントエンド監視〜 10章　セキュリティ監視」

各コンポーネントについての監視方針と代表的なメトリクスの解説です。ここらへんの章は、自分がきになるところからつまみ食いで読んでいく読み方でもいいでしょうね。読む人のエンジニアのバックグラウンドによって、心に刺さるポイントは異なると思います。

最近インフラよりの自分としては、「6章　フロントエンド監視」や「7章　アプリケーション監視」あたりが、自分が知らない知見が盛りだくさんで面白かったです。

「11章　監視アセスメントの実行」

監視アセスメントを実施するのは、何を監視すべきか、なぜ監視すべきかをシステマチックに判断するよい方法です。

改めて全体を振り返って、目の前にあるシステムに対して、監視を再考するための方法が記載されています。こういうのありがたいですね。自分は、仕事がらいろんなお客様のところに行って監視方針の話をする機会が多いのですが、多種多様な業種・業態のお客様に向けて監視について大枠から詳細を詰めていくときに、こういうフレームワークがあると助かります。

おそらくこの本の中で一番短い章なんですが、改めて監視アセスメントというお題目で、この本の全体を振り返ることができるので、読んだ内容の頭の整理にも非常に有用です。

めっちゃ有用「付録C　実践.監視SaaS」

付録なのに、やけに豪華な「実践.監視SaaS」。松木さん（@songmu）記載の付録で、監視SaaSを実際に導入するときの、監視SaaS選定のポイントや何を実際監視すべきかの解説が、文章量は多くないですが非常にコンパクトに凝縮されてまとまっています。

異常にわかりやすいたとえ話がこちら。

もちろん、OSのメトリクスの異常値は、実際になにかの結果でしかありません。筆者は監視を「システムに対する高速健康診断」というたとえをすることがあります。例えば、健康診断で肝機能のγ-GPTの値が悪かったとしましょう。個人差はあるのであくまで仮定ですが、これはお酒の飲み過ぎが原因でしょう。この場合本来監視すべきなのは、酒量です。

つまりは、結果として表出するOSメトリクスは本質的な監視に向かないということが、実感できるかと思います。この「酒量」は、アプリケーション特性によってもろもろ異なるので、そのための監視手段としてハッカビリティを備えていて自分で拡張できる監視SaaSが推奨されています。

その他、外形監視（シンセティック監視）の重要性や、そこからブレークダウンしていくことで原因究明できるようにしておくことの大切さ、外形監視と内部状態を一貫して扱うことの重要性も説明されていて、「あぁ、これ実践やなぁ」と腹落ちします。例としてMackerelが紹介されていますが、ここまで言われれば納得至極。

書籍全体が、実装非依存色が強いため、具体的な製品やアプリに紐付いた描写がすくないんですが、非常にメジャーな監視SaaSのMackerelと紐づけて説明されることで、抽象的な概念と実装がうまく紐付いて腹落ちします。まじこれ付録扱いだけれど、納得感まで求めてこの本を読むのであれば、この付録は必読です。

こちらは、松木さんの執筆後記。合わせて読むとさらに味わい深い。

オライリーの「入門監視」の付録Cを執筆しました | おそらくはそれさえも平凡な日々

まとめ「雰囲気で監視をやっているすべての人が読むべき本」

この書籍のタイトルすごくないすか？最初見たとき、「ど直球タイトルすぎるやろ」と驚いたのをよく覚えています。固有名詞じゃない本で、これだけど真ん中のタイトルも珍しいやろと。それだけ「監視」という領域において、それをメタ的に捉えて考え方の基礎から解説した本が無かったからだと思います。

冒頭にも書きましたが、「なんとなく自分の監視設計って、不安というか一貫して説明できない…」という人には、必ず何らかの学びがある本と断言できるので、アプリケーションエンジニアだろうが、インフラエンジニアだろうが関係なく、システム開発に携わるすべての人に読んでもらいたい本でした。

入門監視 ―モダンなモニタリングのためのデザインパターン

それでは、今日はこのへんで。濱田（@hamako9999）でした。

（おまけ）「入門　監視」についての、エモいツイート

なんか、この本に関わるツイート、全体的にエモうござんす。

入門監視読了！！アンチパターンの章に血塗れにされた

— おさじ (@pypypyo14) 2019年1月20日

おお、一年前に呟いたこれ「入門監視」の付録C経由で見つかった！「監視とは継続的なテストである」https://t.co/XBxewFzMx8 https://t.co/NW5bU1Yohx

— よこち(yokochi) (@akira6592) 2019年1月20日

入門監視で印象深い描写の一つに「ガソリン残量を計測できない燃料タンクを作るな」っていうってのがある。そう、そこの計測方法を作るのはアプリケーション作成側の責務なんだよな

— songmu (@songmu) 2019年1月19日

入門監視を買ったって言うと作者にいいねとかされてるの見るとたしかに「監視」されている感がある

— おじ (@monamomi) 2019年1月18日

例えば、ある認証サブシステム(マイクロサービス)を作る場合、これをどう監視しますか？と問われた時に「プロセスの死活監視をやります」だけでは不十分で、「認証成功・失敗の数をメトリクスとして取得可能にします」とかそういうところの設計も必要なんだよな。

— songmu (@songmu) 2019年1月20日